昨天講的是什麼不給。

今天講另一半:那些可以給的東西,要放在哪裡。

這個問題聽起來很行政、很無聊——不就是選一個地方放檔案嗎?

但我後來發現,它決定了兩件事:誰碰得到,以及更重要的——它會不會真的被用到。

而在整理這件事的過程中,我撞上了一個自己不太想承認的問題。那個放在最後講。

三層

我最後的分法是這樣:

看起來很平常。但這張表有一個地方跟直覺不太一樣,值得講一下。

分層的依據不是「內容類型」,是「誰能碰」

一般在整理文件的時候,大家習慣按主題分:前端一區、後端一區、維運一區。

我沒有那樣分。這三層是按存取權切的。

為什麼?因為 Day 12 那條線是這樣畫的——我要排除的不是「某個主題」,是「某一類風險」。

而風險跟主題根本對不齊:

同一個功能,「它怎麼用」是可以公開的知識,「它連哪個資料庫」是鑰匙。

這兩件事在主題上是同一件事,在風險上是兩個世界。

如果我按主題分,那把鑰匙一定會混在知識裡面被搬來搬去。按存取權分,它從一開始就在不同的層。

所以第一層不是「維運文件」,它是「不管誰問都不會被讀到的那一層」。

這個定義聽起來很繞,但它有一個很實際的好處:當我要判斷一份新資料該放哪,我問的問題只有一個——「這個東西被 AI 讀到,我會不會怕?」 會,第一層;不會,第二層。

不用想它是什麼主題。

為什麼入口要放兩個地方

第三層那個「入口」,是我猶豫最久的。

因為它沒有任何技術必要性——東西就在那裡,給一個連結不就好了?為什麼要在兩個地方都放?

理由很不技術:

因為沒有人會去找一個他不知道存在的東西。

一份文件最常見的死法,不是寫得不好,是沒有人知道它在。

我看過太多這種東西了:某個資料夾裡躺著一份寫得很認真的文件,三個月沒有人打開過。它沒有錯,它只是不在任何人的路徑上。

所以入口放兩個地方,講白了就是增加曝光:

• 團隊通訊軟體——大家每天都在那裡,訊息會被看到
• wiki——大家要找東西的時候,習慣先去那裡翻

一個是推給你的,一個是你主動去找的時候會撞到的。兩種使用行為完全不同,而我不知道哪一種人比較多。

與其猜,不如兩個都放。

而最有效的入口,其實不是任何一個連結

講一件更土的事:現在只要有新進的同事,我會直接把那份東西給他們。

不是「有需要再自己找」,是直接遞過去。

這聽起來完全不像什麼架構設計,但我後來覺得,它可能是整個存放策略裡最有效的一環。

因為前面那兩個入口在做的事,本質上都是等人來。而直接給,是送過去。

一份文件的到達率,跟它寫得多好,幾乎沒有關係。

但這個架構有一個單點,而我很晚才正視它

前面講的都還算順利。接下來這段是這篇真正想講的。

那個能問問題的 AI,跑在我自己的筆記型電腦上。

不是雲端服務,不是公司的伺服器。就是我這台機器。(為什麼是本機,不是雲端,那是 Day 22 的題目,有一整篇在講。)

這件事的後果很直接:

我一離開公司的網路,那個「問問題」的功能就沒了。

我請假、我在外面、我換了一台機器——對其他人來說,那個知識庫就是打不開。

而這裡有一件事讓我很不舒服。

因為 Day 3 我才罵過這件事

我在 Day 3 寫過團隊以前的運作方式:誰對哪一塊比較熟,有問題就去問誰。那套方法很有效率,直到那個人離開,整塊知識瞬間歸零。

我當時的結論是:知識不該綁在一個人身上。

然後我做了什麼?

我做了一個知識庫,來解決「知識綁在人身上」的問題。而那個知識庫,綁在我的筆電上。

同一種病,換了一個更現代的外殼。

我想很誠實地講一下這個發現的感覺:它不是那種「啊哈我發現了」的愉快,比較接近一種被自己打臉的難堪。因為我花了好幾天在寫「不能依賴某個人的記憶」,結果整套東西的可用性,取決於我今天有沒有連上公司的網路。

所以需要一個不依賴任何人的版本

處理方式其實不複雜,但它需要先想清楚一件事:

這個知識庫的哪些部分,是真的需要 AI 的?

拆開來看,它其實是兩種東西疊在一起:

• 內容本身——那些頁面說明、流程、常見問題。這部分是靜態的文字,根本不需要模型。
• 問答介面——用自然語言問一句話,它去找相關的段落回給你。這部分才需要模型。

而我一開始把它們當成一個東西,所以整包都跟著模型一起活、一起死。

分開之後,答案就出來了:做一個靜態版本。

一份不需要模型、不需要我的機器、不需要連上公司網路就能打開的東西。搜尋的部分降級——不做語意理解,改成關鍵字比對,把問題對到現成的題目上。

這是當時的做法。後面這一塊又換過一次——現在靜態版跑的已經不是「比對現成題目」,而是跟完整版同一套檢索。

而它換了之後的失敗長什麼樣子,跟我這裡預期的也不一樣。那是 Day 21 的事。

我知道這個降級是有代價的:它答不了沒被預先想到的問題,問法換一種可能就找不到。

但我後來的想法是:

一個答得不夠好但隨時打得開的東西,勝過一個答得很好但今天剛好打不開的東西。

因為後者在「打不開」的那一刻,價值不是下降,是歸零。而那一刻,通常就是有人真的需要它的時候。

我從這件事學到的一條規則

我後來把它寫成一句話:

一個知識庫的可用性,不會高於它最脆弱的那個依賴。

而人們在算可用性的時候,習慣只算技術的部分——伺服器、網路、服務。很少有人把「某個特定的人在不在」算進去。

但在小團隊裡,那往往才是最脆弱的一環。

所以現在我判斷一個東西可不可靠,會多問一個問題:

「如果我明天請假,這個東西還能用嗎?」

如果答案是不行,那它就還沒做完——不管它現在跑得多好。

順便講一個延伸的好處

做靜態版本的時候,我原本以為只是備援。後來發現它有一個沒預期到的作用:

它可以被帶出去。

完整版綁在內網,而靜態版是一份自己完整的東西。要給一個還沒有帳號的新人?給靜態版。要在會議上帶一段?打開靜態版。

可攜性本身就是一種可用性。

一份要先申請三個權限才看得到的文件,和一份點開就有的文件,對一個第一天上班的人來說,差別不是「方便一點」,是「會不會用」。

明天:那權限到底要給到哪裡?

今天講的是東西放在哪、誰碰得到。

而「誰碰得到」這件事,還有一個更尖銳的版本我還沒處理:

一個剛進來的新同事,要給多少權限?

我當時在想這個問題的時候,發現我腦袋裡的那套判斷,跟我用來決定「要給 AI 看什麼」的那套,長得幾乎一模一樣。

明天那篇要講的就是這個對照——以及它為什麼不是一個技術問題。